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[57] ABSTRACT 

A system for facilitating commercial transactions, between 
a plurality of customers and at least one supplier of items 
over a computer driven network capable of providing com- 
munications between the suppHcr and at least one customer 
site associated with each customer. Each site includes an 
associated display and an input device through which the 
customer can input information into the system. At least one 
supplier is presented on the display for selection by the 
customer using the input device. Similarly it^ns from a 
supplier can be displayed for the customo' to observe. 
Associated with a supplier of such items is an item database 
including information on presented items. E^ncing subsystem 
receives inf onnation from the item database to determine the 
cost associated with a presented item. In addition a customo' 
information database stores information relating to the cus- 
tomer. Associated with each customer is a customer moni- 
tcmg object for each customer. The customer monitoring 
object is created by referencing inf onnation, relating to that 
customer, which had been stored in the customer informa- 
tion database and when the customer selects a supplier. The 
customer monitodng object is configured to operate by 
responding to customer enquiries regarding a presented item 
by retrieving information relating to the item and presenting 
the information to the customer; receiving a customer's 
selection of a presented item; receiving customer 
conununications, indicating a desire to receive the item; and 
passing a communication to initiate the delivery of the item 
to the customer. 

49 Claims, 15 Drawing Sheets 
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COMPUTER SYSTEM AND METHOD FOR such as simultaneously offering a multitude of price 

ELECTRONIC COMMERCE discounts, pcdbiming targeted advertising, or collecting 

sales feedback. 

BACKGROUND Another conipany, Open Market, is developing a similar 
1. Technical Field 5 electronic catalog system consisting of a HypeiTcxt Markup 
This invention relates to a system for conducting inter- Language (HTML) authoring tool (called Storebuildcr), and 
active electronic commerce among a pluraUty of a server (caUed Webserver) connected to an integrated 
participants, and more particularly to a computer architec- back-end commerce system (caUed TtansactionLink). This 
turecon^sing a family of distributed, interface-compatible system appears to share similar characteristics and disad- 
commerce subsystems, where each electronic store operato- vantages as the Netscape system, 
selects a particular combination of subsystem inq>lementa- TTius, existing computer architectures for on-line elec- 
tions to meet stwe specific operating needs. tronic commerce are service providCT-specific ardiitectures 
2 Background are platform-limited (the Internet) and require confor- 
tt is desirable to provide a system and method for con- * ^ ^^T^^ f"?" subsystem 
ducting commerce via an electronic means, such as a com- ii^pl^tations Such dosed architectures may greaUy 
puter networic cable television network, or direct dial tot their expandabihty or widesprea^ 
modem. Previous attempts to provide electronic commerce widespread acceptance oo^urs, this is likd^ 
subsystems have been custom tailored to an individual ovff anuinber of competmgsystenis,whosek^of interq^ 
commerce offering, and have not been adaptable to be able erabihty may force customers to log on to d^erent ardn- 
to provide a versatUe system capable of supporting a wide '° ^« far diffoent transactions or force vendors to mam- 
range of providers of goods and services. ^ equivalent operations on different architectures. Sudi 
^ J , architectures are aimed at a customer<etailer level of 
To T^t tas need, sevaal coirpames have developed ^^^^^^ ^ ^^at level, they do not snRpcrt the 
computer architectures for online electronic catalog sales . ^ i , , ^ > i • * 

- 1 *u T * * ^ u intra-level competition (e.g., Compuserve's dectronic store- 

usmg,farexainplc,thefcternetasatransp^ 25 f„„t versus America Onlin^s customer electronic 

transmit date representmg purchase requests between a ^^^^^^ ^ dtaiacterizes real-world commerce. Hie 

ptopnetary browser and server product pam ardiitectoes arc also too flat to support the complex Inter- 

For example, Netecapc Commmi^ations uses its j^^^j hierarchies (e.g., manufacturer-distributor-retailcr 

Navigatoimetsite World Wide Web (WWW) browsec/server relationships) that characterize real-world commerce, 

pair. A buyer uses a Navi^itor to select a sdler s Nctsite 30 Finally, the architectures do not accommodate the marketing 

server (sort of an clectromc storefront), whidi is in turn necessary for customer generation. Overall, the 

coupled to standard application servers (back-end architectures may be thought of as elcctionic cata- 

subsystems), e.g.. a cretht server or a member ^^.^'^ log architectures rather than general electronic conmieice 

collecting demographic infonnatLon on customers. These ardiitectures 
servers contain the business rules defined by the seQer, e.g., 33 

what credit cards are accepted and what customer informa- OBJECTS OF THE INVENTION 

tion is trmiked during eadi sal.^ Some of these sorcxs are ^ ^^^^^ ^ ^ ^ 

connected to external, «to4-party services, e.g., the aedit ^ ,^ fadUtating commercial transactions over a com- ; 

s«av^ an external credit card processmg networi. or the ^^^^ network capable of providing communications 

m«iber server to an external demogr^hics jjocessmg 40 between a suppUcr and at least one customer site associated 

m«tale. Tlie actual apphcations e.g., on-line pubhshmg or ^ ci^omer and including an input means and a 

catalog sales, are represented as extensions of the apphca- Hisnlav 

tion servers. Hquivalently, the ^>pIication servers are said to , . „ . ^ , . 

be instantiated in the appUcations. TTie net result of this / ^J*^* ^ ^ P^^^f^ ^ 

approadi is that the business rules (from the application 45 commerce computer architecture whidi am 

s^crs) are embedded into the appHcations along with the accommodate a wide variety of implementaUons. For 

appUcation logic or presentation. ardutecti^ should accommodate the use of 

THis model has a number of disadvantages. First, the ^^fZT^^'C'mo^^^ 

system is limited to a single communicati^ platform, the commerce with httle modification. 

Internet ThisisbecausetheNavigator/Net&itesoftwareused 50 . ^^v'^^*^^'^ to provide artual 

to implement the modd is dependent on the 'Hansmission miplementations of some commerce subsystems where 

Control Frotocol/Intemet Protocol (TCP/IP) used in fee existing commerce subsystems used for physical commerce 

Internet The model has no provisions to aUow communi- <^-8- marketing subsystems) are not reaxttly extendible to 

cations to platforms not using TCP/IP, for example, inter- electronic commerce or where those subsystems do not 

active TV. Second, in the Netsc^ modd, business flex- 55 <J"^cntty exist 

ibility is low because of the intermingling of business rules It is still another object of the invention to provide an 

and q>p]ication logic. It is more difBcult to modiiy a portioD electronic commerce con4)uter ardiitecture, comprising a 

of the resulting monolithic application than it would be to family of interconnected commerce subsystems, where 

modify a portion of a smaller module of a modular appli- changes can be made to one subsystem without affecting die 

cation. This may have negative inq>acts on reliability and 60 o^ber subsystems. 

availability, because in certain cases it may be necessary to It is yet another object of the invention to provide an 

shut down the system to make changes that must be syn- electronic commerce system, comprising a family of inter- 

chionized between two more conyxments. Third, such connected commerce subsystems, where the subsystems can 

dectronic catalogs support product display and secure pay- be distributed across many different platfoims and networks, 

ment processing, but not the marketing activities needed to 65 Yet a further object of the invention is to provide an 

induce customers into reading the electronic catalogs. Thus, dectronic ccnnmerce system which dosdy replicates com- 

there are no counteiparts for physical commerce activities merdal transactions in evoyday life. As such it Is another 
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object of the invention to provide for an electronic assistant 
to assist a customer during interactions with the system to 
fadlitate electronic commercial transactions. 

SUMMARY OF THE DSrVENTION 
Briefly, therefore, this invention provides for a system foi 
facilitating commercial transactions, between a plurality of 
customers and at least one supplier of items. The commer- 
cial transactions occur over a computer driven network 
capable of providing communications between the supplier 
and at least one customer site associated with each customer. 
Each site includes an associated display sudi as a personal 
computer, set-top box, a touch sensitive screen, a touch tone 
telephone or any other device capable of reproducing to 
audio or video information to a human being. Each site 
typically also includes an input means such as a keyboard or 
conqjuter "mouse" through which the customer can input 
information into the system. 

TTic system of the invention facilitates the presentation of 
at least one supplier on the display for selection by the 
customer using the input means. Similarly items from a 
suppUer can be displayed for the customer to observe. 
Associated with a supplier of such items is an item database 
including information on presented items. Pricing means 
receives information from the item database to determine the 
cost associated with a presented item. In addition a customer 
information database stores infoimatton relating to the cus- 
tomer. The system also comfHises myeans for creating a 
customer monitoring object for each customer. 

The customer monitoring object is created by referencing 
information, relating to that customer, which had been stored 
in the customer information database and when the customer 
selects a supplier. The customer monitoring object is con- 
figured to operate by responding to customer enquiries, 
communicated througlh the input means, regarding a pre- 
sented item by accessing the item database to retrieve 
information relating to said item and to present said infor- 
mation to the customer by means of the display; receiving a 
customer's selection of a presented item through the input 
means; communicating with the pricing means to cause the 
cost of the item to be determined; presenting the cost to the 
customer by means of the display; receiving customer 
communications, through the input means, indicating a 
desire to receive the item; and passing a delivery initiation 
communication to initiate the delivery of the item to the 
customer. 

The customer monitoring object can also be configured to 
maintain a Hst of selected items and to present the customer 
with a total cost of all selected items for approval before the 
customer monitoring object passes the delivery initiation 
communication. As part of this function, the customer 
monitoring object could be configured to present the cus- 
tomer with an opportunity to deselect an item whereupon the 
customer monitoring object causes the total cost of the 
remaining selected items to be redetermined and presented 
anew to the customer. 

The system further comprises an order fulfillment initia- 
tion systemi, responsive to the delivery initiation communi- 
cation from the customer monitoring object, for initiating 
proceedings to cause the item desired by the custonoer 
delivered to the customer. To enable this, it is preferable that 
the order fulfillment system include an interface with a 
shipping facility for facilitating the shipping of the desired 
item to die customer. TVpically the shipping facility will be 
an existing facility known in the art 

To arrange payment for any transactions, the system of the 
invention further comprises a payment handla for initiating 
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customer payment for the desired item. The payment handler 
is responsive to communications from the customer moni- 
toring object. Also, the customer monitoring object is con- 
figured to confirm to the customer that the order for the item 

5 has been successfully processed. 

Furthermore, the system includes a payment validation 
system by means of which the customer monitoring object 
receives the information related to the forms of payment 
available to the customer and presents the customer with a 

10 selection of the forms of payment The customer also enters 
a first security code, related to a selected form of payment 
Thereupon, the first security code is validated by compari- 
son to a second security code available to the customa* 
monitCTing object Payment for the item is initiated if the 

15 first security code is validated. 

The system of the invention also allows for incentives to 
encourage the customer to con^lete a transactions. Such 
incentives could include cost reductions such as price dis- 
counts. Information regarding these cost reductions is stored 

^ within the system, often in association with, specific infor- 
mation relating to the customer and also associated with a 
supplier's items. The pricing means receives relevant parts 
of the cost reduction information to calculate the cost of the 
associated item. Topically, the customuer monitoring object is 

^ configured to receive cost reduction information communi- 
cate the reduction information to the pricing means. 

The customer monitodng object is also configured to 
confirm to the customer that the order for the item has been 

^ successfully processed. 

The system of the invention further comprises suppUer 
control means for receiving input, from a supplier, for 
changing the cost reduction information. One way of doing 
this is by having the supplier control means receive an input, 

3^ from a supplier, at a first time defining changes to the cost 
reduction information for a second time later than the first 
time. This enables a supplier to define in advance both the 
timing and the magnitude of the discount that is applied. 
The customer monitoring means can be "short lived** and 

40 cease to operate on the termination of a transaction. Trans- 
action termination is generally effected by a command from 
the customer. Alteratively, when the customer terminates 
interaction with the supplier, the customer monitoring object 
could temporarily cease to operate. In this case, information 

45 regarding at least the interaction is stored for retrieval at a 
subsequent time at which the customs interacts with the 
supplier. At that time the customer monitoring object recom- 
mences operation without being recreated. 
The system fiirther comprising a means for accessing the 

so customer information database and for creating a particq>ant 
program object The participant program object includes 
customer specific information retrieved from the informa- 
tion database. The participant program object is in commu- 
nication with and electronically represents the customer to 

55 the customer monitoring object The participant program 
object is created at the time an interaction between the 
customer and the system commences. It preferably includes 
information related to forms of payment available to the 
customer. 

60 The system may also comprise an observation system for 
receiving and maintaining customer interaction information 
relating to at least one customer's communications over the 
computer driven network. Preferably, the supplier control 
means is in communication with the observation subsystem 

65 and receives customer interaction information for display to 
the supplier. The supplier control can include an inf cvmation 
processor for processing received customer interaction 
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infonnatioD; and means for sdecdvdy displaying at least a 
pait of the processed customer interaction inf onnation to the 
supplier. 

Additional features of the invention will become apparent 
upon examination of the description which follows particu- 
larly with reference to the accompanying drawings. 

DESCRffTION OF THE DRAWINGS 

In the accoiiy)anying drawings: 

FIG. 1 is a schematic representation of an electronic mall 
exemplifying the electronic commerce architecture of this 
invention. 

FIG. 2 schematically depicts an embodiment of the inven- 
tion configured to support transaction processing. 

FIG. 3 depicts a compartment level view of the system of 
FIG, 2. 

FIG. 4 depicts a compartment level view of the system, 
similar to that in FIG. 3 but with a plurality of Storefront 
Systems. 

FIG. 5 schematically represents an outline transaction 
using the system of the invention. 

FIG. 6 depicts the completion of the online transaction of 
HG. 5. 

FIG: 7 dq)icts the process by which a customer selects 
items for purchase in an online transaction of FIG. 5. 

FIG. 8 dqiicts the completion of the online transaction in 
the commerce system illustrated in FIGS. 5 to 7. 

FIG. 8A depicts the steps of FIG. 8 performed by the Sales 
Representative Program Object 

FIG. 8B depicts tfie steps of FIG. 8 performed by the 
Payment Handler tnterfaoe and Participant Program Object 

FIG. 9 depicts one example of the use of a User Interface 
to select the preferred payment method. 

FIG. 10 schematically illustrates the creation of incentives 
in the system of the invention. 

FIG. 11 depicts a Pricing Rule Structure. 

FIG. 12 depicts the operatioa of a Dashboard Client to 
maintain the data needed to operate a store&ont 

FIG. 12A depicts one view of the Dashboard Qient as it 
appears to a storefront operator. 

FIG. 12B depicts a second view of the Dashboard Qient 
as it af^>ears to a stoorefront operator. 

FIG. 13 is a flowchart that depicts the operation of the 
Mcing Engine ^plying Coupons according to the inven- 
tion. 

FIG. 14 schematically illustrates the registration process 
of the Observations Subsystem 

FIG. 15 schematically illustrates the event notification 
process of &e Observations Subsystem. 

DESCRHnON OF EMBODIMENTS 
L Overview 

This invention relates to a computer architecture for 
on-line commerce which defines an electronic infrastructure 
to enable a full range of commercial transactions analogous 
to those occuiring in physical commerce. 

It is evident that a participant in electronic commerce 
might include a manufacturer of goods selling to a 
distributor, a distdbutcn: buying from a manufacturer and 
selling to a retailer, or a retailer buying from a distributor 
and selling to a consumer. The items sold need not be limited 
to goods, but could also include services such as videos 
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downloaded to a viewer's multimedia display, as well as 
deliveryless transactions such as selling stock shares held in 
a central repository. 
The Electronic Mall 

5 ft is useful conceptually to think of electronic commerce 
as exenq>lified by an electronic mall comprising a collection 
of suppliers of items such as goods or services, such as 
electronic stores, analogous to a physical mall comprising a 
collection of physical stores. In this example, each commer- 

10 dal transaction constitutes a sale from an electronic store to 
a customer of the electronic stc»:e, where a customer can be 
any participant in the electronic commerce architecture. 

ft should be noted, however, that electronic malls and 
stores are of vastly broader scope than their physical coun- 

15 terparts because the electronic mall can contain electronic 
stores composed of independent functional subsystems 
located at various platforms and networks in an electronic 
hyperspace encompassing the Internet, interactive TV, exist- 
ing legacy systems, and many other electronic venues. 

20 Moreover, the electronic store is not limited in ge(^aphical 
reach (e.g., a national store is possible), in goods sold (e.g., 
physical products, digital iirfcrmation, and deliveryless 
transactional services are all possible), or to customer- 
merdiant relationships (e.g., an entire distribution chain 

25 from manufacturer to consumer can be accommodated). 
FIG. 1 shows an electronic mall, generally indicated as 
10, that exemplifies the electronic commerce architecture 
provided by this invention. A Customer 12 enters the elec- 
tronic mall via a us^ interface 13, where the customer is 

30 presented with a choice of displayed Electronic Stoarefconts 
14. Hie user interface 13 may be a personal con^uter, 
set-top box, a touch sensitive screen, a touch tone telephone 
or any other device capable of reproducing to audio or video 
information to a human being. It typically includes an input 

3S means such as a keyboard or computer "mouse*' through 
which the coirputer can input information into the system. 

The customer enters a particular electronic store by select- 
ing its Electronic Storefront 14, e.g., by clicking on an icon 
with a conventional selection or input device such as a 

40 mouse/curser device toud^ad. As the customer enters the 
store, Internal Coimnerce Subsystems 16 are invoked by 
Electronic Storefix>nt 14 to represent the store's interactions 
with the customer. 
As the customer decides what items to purdiase, External 

45 Commerce Subsystems 18 may be invoked to complete the 
transaction. For example, VESA's credit card network may 
be used for payment followed by FedEx's Powership shq>- 
ping management software for shipping. 

In the meantime, the store's management can use a Store 

50 Management Dashboard 20 to interface and control the 
Commerce Subsystems 16 and 18; for exaiiq}le, to establish 
in-store sales as incentives to the customer. 

The Internal Commerce Subsystems 16, External Com- 
merce Subsystems 18, Electronic Storefront 14, and Store 

55 Management Dashboards 20 interact with each other 
through Internal Commerce Subsystems Interfaces 24 and 
External Commerce Subsystems ^terfaces 22. 
H Subsystem Overview 

Following from the above it may be apparent that each 

60 electronic store in .an electronic mall must be able to manage 
customer information, support targeted advertising, perform 
market researdi, execute on-line marketing programs like 
discount pricing, and ensure secure and reliable order and 
financial transaction processes, all within the context of its 

65 own operating style. 

This invention provides such flexibility at &e individual 
store level while supporting simultaneous transactions 
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among a plurality of dectronic stores, by defining a family tion provides only standardized interfaces to flie commerce 
of elementary Commerce Subsystems 16 and 18 necessary subsystems, while in the latter, the invention can provide 
to support the various elements of electronic commerce, and acmal subsystem implementations as well as the intafaces. 
allowing each store to select a particular combination of This distinction provides great openness and flexibility by 
subsystems interconnected in a particular patta-n to suit its 5 allowing electronic commerce participants to select External 
particular operating style. Commerce Subsystems from a variety of curcentiy existing 

It may be useful to think of these Commerce Subsystems business subsystems, while providing Internal Commerce 
as "distributed objects'* accessible to various of the stores Subsystems for those Commerce Subsystems where cur- 
and indeed to multiple stores, at tfie same time. Although not rently existing business subsystems either do not exist or are 
illustrated in FIG. 1, these Commerce Subsystems include: lO unadaptable from physical to electronic commerce. In either 
an Incentives Subsystem; an Observations Subsystem; an case, the architecture provides standardized interfaces 
Order FuUiUment Subsystem; a Participant Subsystem; a througji which Commerce Subsystem in^lcmenlations corn- 
Payment Handler; a Pricing Subsystem; a Product Database; municate with the architecture. Thus, the distinction 
a Promotions Subsystem; a Sales Representative Subsystem; between External and Internal is somewhat arbitrary, as it 
a Redemption Registry; a Security Subsystem; a Shilling 15 reflects the conmicrcial availability of existing subsystem 
Subsystem; and a Tax Subsystem technologies rather than any fundamental difference 

The Customer Accounts Subsystem is a store-specific between the two subsystem categories, 
repository which holds information on that stare's custom- Thus, each of the Internal and External Commerce Sub- 
crs* demographics and payment habits. Likewise, the Incen- systems is a self-contained, independent module connected 
tives Subsystem is a marketing module which allows stores 20 into the architecture through a standardized interface. The 
to establish discount programs such as in-store sales, modules as a whole can be arranged in any combination for 
coupon-based discounts, frequent buyer programs, and any particular store. Note that the above categorization of 
quantity discount cards. Commerce Subsystems as Internal or External is exen4>lary. 

Similarly, the Participant Subsystem is a shared repository not mandatory. That is, a particular subsystem may have 
within the system architecture which stores general infer- 25 botfi Internal and External embodiments. For example, some 
mation on participants conducting electronic commerce with vendors may develop proprietary External Commerce Sub- 
each other. TTie participants might include manufacturers, systems to rq>lace the Internal Conmierce Subsystems origi- 
distributors, retailers, and customers; and information might nally provided by this invention. In those cases, tiie system 
include names and mailing addresses, preferred payment architecture would be able to accommodate either an Inter- 
methods, etc. 30 or External implementation of the Commerce 

For exanq)le, in the case of a household comprising Subsystem, with each electronic commerce participant being 
multiple customers, some customer data will be household- able to select a combination of spedfic implementations that 
^>ecific (e.g., a single shipping address) while other cus- best suits the participant's needs, 
tomer d^ may be customer or store-specific (e.g., Mom's External Coommerce Subsystems 

Macy's credit card number). This separation of household 35 Many existing Commace Subsystems used for physical 
and customer data woidd also be useful for promotions commerce can be used for electronic commerce without 
based on household demographics, and o&er ^plications, modification. These technologies are referred to as External 
where it is not necessary to send repeat advertisements to all Commerce Subsystems. Such subsystems operate identi- 
members of a household. cally whether the sale occurs in a physical or electronic 

The Observations Subsystem provides a system for 40 store, so that their implementations are the same in botib 
recording events representing observable data that results physical and electronic commerce. They could include: 
fi-omcustomo: interactions. A program object called a **col- Customer Accounts Subsystem, Participant Subsystem; 
lector" conamunicates events to an evcntredpient. The event Order Fulfillment; Payment Handler, Product Database; 
recipient can either record the event for subsequent histod- Shipping; and Tax. 

cal analysis, or present it for real time analysis. 45 Examples of well-known existing inqjlementations of 

The Electronic Storefiront, which is analogous to a jrfiy si- these subsystems are: VISA'S computerized aedit card 
cal store's physical layout, is the gr^hical user interface network (Paynient Handler), various catalog sales' central 
presented to a customer browsing that store, warehouse opo-ations (Order Fulfillment), FedEx's on-site, 

The Store Management Dashboard 20 allows store man- personal con^)Uter-based shipping calculator (Slipping), 
agemcnt to change prices, offer incentives, collect customer- 50 and AVP's tax calculator (Taxing), 
based and store-based sales data, and perform targeted Many physical stores will have different External Con^ 
advertising, i.e., interact with the various Internal and Exter- merce Subsystems that they will want to continue using in 
nal Commerce Subsystems discussed earlier. H is anticipated the context of an electronic store. For example, other Pay- 
that stares will want to use their own proprietary Electronic ment Handler systems might include CheckFree's automatic 
Storefronts, so the architecture provides an interface to be 55 check handling system for non credit-card acceptors or 
used by an existing Electronic Storefront rather than pro- in-house "legacy systems" for large department store chains, 
viding the Electronic Storefront itself. For example, existing Therefore, the system architecture must accommodate a 
commercial services having proprietary electronic store- wide variety cf cxistinjg subsystems. Rather than developing 
fronts (e.g., America Online's or Conq)uscrve's home shop- new subsystems to displace individual stwes* established 
ping forums) will probably want to continue to use those 60 preferences, the system architecture provides a set of appli- 
storrfronts even if they become networked into a broader cation program interfaces (APIs) tiirough which owners or 
dectronic commerce architecture provided by this inven- vendors of External Commerce Subsystems can easily 
tion. 'Vr^" their products for coimection to the general system 

Architectural Openness and Flexibility architecture. 

As discussed briefly al>ovc, the Conmierce Subsystems 65 Internal Commerce Subsystems 
may be categorized as either external or intemaL Hie The remainder of the Conmierce Subsystems are called 
difference between the two is that in the former, the inven- Internal Commerce Subsystems— those where existing sub- 
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systems far physical ooinmerce can not be diiectly used in graphic data, and methods available to the participant for 

electronic commerce, so that separate electronic counter- payment Access by a store to the information about a 

parts must be developed for use by electronic stores. participant is controlled by a flexible mechanism in the 

Such Internal Commerce Subsystems might include: Participant Subsystem. This mechanism suppcEts enforce- 

Inccntives; Observations Subsystem; Participant Sub- 5 ment of a variety of privacy policies. These policies may be 

system; Pricing; Promotions; Sales Representative; and specified by the operator of the Commerce System, by the 

Security. individual participant, or by a combination of the two. 

Some of these subsystems, though not currently in exist- Different privacy policies may be specified for each element 

ence for use in electronic commerce, nevertheless use well- of the participant data for each individual customer. The 

established, commercially available technologies. Hiese lo policy data is stored with a Participant Program Object 112 

could include Oracle or Sybase databases for the database as part of the privacy controls, in a Participant Subsystem 

components of the Observations and Participant which will be described in greater detail with reference to 

Subsystems, and RSA Public Key encryption technology for FIG. 5. 

the Security Subsystem. These Internal Commerce Sub- For each payment method, the Participant Program Object 

systems are developed by singly wrapping the aforemen- 15 112 contains a short token used to describe the payment 

tioned technologies with the appropriate hooks to interface method and a password that will be used to validate attempts 

with the standardized APIs. The process is similar to that to use the payment method. 

third party developers would use to create interface- Typically, the Participant Program Object 112 is created 

compatible External Commerce Subsystems. for a participant 12 at the time that the participant is 

The four remaining Internal Commerce Subsystems, 20 registered with the electronic service from wtdch he or she 

whidi are not generated by modifying existing technologies, will interact with the commerce system. For exanq>le, if the 

are the Incentives Subsystem, the Pricing Subsystem, the electronic service is an online service such as Conqjuserve 

I^omotions Subsystem, and the Sales Representative Sub- or America Online, a Participant Program Object 112 is 

system. The details of these will be apparent from a reading created at the time the customer enrolls with the online 

of the specification as a whole. 25 service. likewise, if the electronic service is a cable televi- 

HL Iiiq)leinentation sion provider, a Participant I^ogram Object 112 is created at 

To inaplementthe above, and as will be apparent from the the time that the participant 12 begins subscribing to the 

description of FIG. 2, the system comprises a set of program cable television provider. In this way, sensitive inf onnation 

objects. such as credit card account numbers and passwords may be 

A program object is an integrated collection of data and 30 provided using a secure means at account initiation, 
functions that describe an entity or business function, and The Participant Program Object 112 communicates with a 
the operations that can be perfonned on ot by the entity or Customer Monitoring Object or Sales Representative Pro- 
business function. Program objects can also access gram Object 114. Sales Representative Program Object 114 
databases, and serve as interfaces to non-object-oriented is a program object that is created when the customer selects 
subsystems. Tht program objects may be, for example, 35 a store. The Sales Rq}resentative Program Object 114 has 
objects in conq)liance with the Object Management Group* s access to information, kept by the store, about the customer 
(OMG's) Conamon Object Request Broker Architecture and also controls the flow of a transaction processing session 
(CORBA). and forms part of an Internal Commerce Subsystem 16 

CORBA provides mechanisms by which objects may shown in FIG. 1. As wiU be described in detail. Sales 
transparently make requests and receive responses. CORBA 40 Representative Program Object 114 is used to obtain infer- 
also provides for an Object Request Broker (ORB), which mation regarding items that are the subject of the 
provides interoperability between applications on different transaction, and initiate dearanoe for payment and order 
computers in heterogeneous distributed environments and fulfillment 

seamlessly interconnects multiple object systems. The Tlie Sales Representative Program Object 114 is analo- 

advantage of compliance with an architecture sudi as 45 gous to a sales representative in a store. Just as a sales 

CORBA is that the program objects may be distributed representative has tiie responsibility of monitoring the cus- 

among various computers according to the business needs tomers activity by being aware of prices of products and 

and responsibilities of tiie entities involved in the system. discounts available to the customer, and by initiating 

FIG. 2 illustrates a number of the program objects nec- conviction of the transaction, the Sales Refwesentative 

essaiy to implement an embodiment of the invention. As 50 Program Object 114 cames out these tasks in the online 

such, the figure shows a plurality of program objects inter- commerce system. 

acting to support the execution of a conomercial transaction. Interaction between the Sales Representative Program 

To begin with, a participant or customer 12 interacts with Object 114 and the customer 12, to communicate infonna- 

the system 10 by way of a user interface 13. User Interface tion about, for example, items desired to be purchased, is 

13 may be in fte form of a video terminal, a caMe television 55 through the User Inteif aoe 13. 

setptop device, a touch-sensitive kiosk screen, a touch-tone Hie Sales Representative Program Object 114 communi- 
telephone, or any other device or combination of devices cates with a Product Database 116 through Pricing Engine 
capable of reproducing or otherwise displaying human Intel- 120. Product Database 116 is part of the External Commerce 
ligible audio and/or visual infannation to a customer 12 and Subsystems IS and is a computer file or set of computer files, 
capable of converting hiunan input to a discrete signal 60 including, if necessary, supporting software components for 
capable of being recognized by a computer. the retrieval of data. Product Database 116 includes infer- 
Notwithstanding this interaction, however, it is aPartici- mation regarding items that are offered as the subject of 
pant ftogram Object 112 that represents the customer 12 in transactions. This information includes the name of the item, 
the commerce system. The Participant Program Object 112 item identification numbers, standard price for the item, 
contains infonnation that identifies the participant 12, and 65 manufacturer, etc. The Product Database 116 may be imple- 
additional infonnation about the participant, for example, mented using any of a number of commercially available 
the participant's name, address, privacy controls, demo- database systems, such as Oracle or Sybase. The Product 
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Database 116 accepts function calls from the Sale Repre- 
sentative Program Object 114 to provide information about 
a particular item. 

Also provided is Distributor Program Object 118, which 
is part of the Internal Commerce Subsystems 16, and is a 5 
program object that provides information regarding Cou- 
pons 119 to the Electronic Store&ont 14. Coupons are data 
structures that describe incentive programs in the form of 
discounts that made available to the customer to encourage 
purchase of items, and are further described below. 10 

A Pricing Engine 120 is responsive to function calls from 
Sales Reftt-esentative Program Object 114 is also provided. 
Rtidng Engine 120 is a program object that provides infor- 
mation about the price of a set of items selected for purchase. 
The Pricing Engine 120 accesses the Rroduct Database 116 15 
to determine attributes of selected items, and applies incen- 
tives obtained from Distributor Program Object 118 to 
determine a price that will be charged to the customer. 

The Tax Engine 122, part of External Commerce Sub- 
systems 18, is a program object that detennines what tax, if 20 
any, should be applied to a particular transaction, based upon 
the items that are the subject of the transaction, the geo- 
gr^hical locations of the participant and the electronic 
commerce system, etc. The Tax Engine 122 is responsive to 
function calls from Sales Representative Program Object 25 
114 and may be implemented, for example, using a con^ 
mercLally available tax calculation system, such as the AVP 
Tax Engine. 

The Shipping Cost Engine 123, part of External Com- 
merce Subsystems 18, is a program object that determines 30 
the cost, if any, of shipping purchased items to the location 
designated by the customer, based upon the prc^>erties (such 
as weight, size, and special shipping requirements) of the 
items that arc the subject of the transaction, the geographical 
locations of the participant and the electronic commerce 35 
system, etc. The Shipping Cost Engine 123 is responsive to 
function calls from Sales Representative Program Object 
114 and may be implemented, for example, using a com- 
mercially available shipping cost calculation system. 

Payment Handler Interface 124 is provided to initiate 40 
payment for a transaction. This is a program object that is 
responsive to Sales Representative Program Object 114. 
Typically, the Payment Handler Interface 124 will serve as 
a front-end to convert an object-oriented function call, such 
as a CORBA call, to a call to an External Payment Handlo- 45 
126, part of External Subsystems 18. The Extemal Payment 
Handler 126 may be implemented using a commerdally 
available payment handling system, such as Visa Coipora- 
tion's VISAnet (not shown). 

To initiate delivery of the selected items to the customer 50 
Order Fulfillment Subsystem 128, a program object that is 
responsive to Sales Representative Program Objert 114, is 
provided. Topically, the Order Fulfillment Subsystem 128 
will serve as a front-end to convert an object-oriented 
function call such as a CORBA call to a call to an external 55 
subsystem that performs order fulfillment. An example of 
such an external subsystem is Order Fulfillment Legacy 
Subsystem 130. The Order Fulfillment Legacy Subsystem 
130 may, for example, be a stare's existing subsystems for 
delivering a product or a service to the consumer. 60 

This figure also depicts one possible configuration of 
components distributed among multiple logical conq>art- 
ments of the commerce subsystem. A logical compartment 
may be a distinct computer system, or it may be a set of 
resources in a computer system or set of oonq)uter systems 65 
to which the enterprise responsible for the compartment has 
access. 
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In Uie example depicted in this FIG. 2, Participant Pro- 
gram Object 112 and User Interface 13 are configured in 
what can be called a Customer Contact System 140. Cus- 
tomer Contact System 140 may be, for exanaple, an online 
service such as Compuserve or America Online, an appli- 
cation interface at a cable television site accessed remotely 
by a customer using a set-top box, or a World-Wide Web 
(WWW) site on tiic Internet accessed by a customer using a 
WWW browser application across a TCP/IP connection. 

Similarly, the Sales Representative Program Object 114. 
Product Database 116, Pricing Engine 120, Tax Engine 122, 
Sh4)ping Cost Engine 123, Payment Handler Interface 124, 
External Payment Handler 126, Order Fulfillment Sub- 
system 128, and Order Fulfillment Legacy System 130 are 
configured in an In-Store Processing System 142. In-Store 
Processing System 142 may be, for example, a computer 
system used to administer one or more of the electroiuc 
Storc&onts 14 shown in FIG. 1. 

FIG. 3 depicts only the compartment level view of the 
system depicted in FIG. 2. In-Store Processing Systaa 142 
is depicted in communication with Customer Contact Sys- 
tem 140. 

As an expansion of this view, FIG. 4 depicts a coni^art- 
raent level view of the system, with a plurality of In-Store 
Processing Systems 142. In such a configumtion, the com- 
merce system operates to facilitate commerce with multiple 
commercial entities, analogous to the shopping mall sup- 
porting multiple stores as described above. 
IV. Transaction Processing 
Overview of an Electronic Store Transaction 

To more fUUy understand the operation of the invention, 
it is useful to concentrate on a transaction in a single 
electronic store. FIG. 5 shows an overview of a simplified 
logic flow for a typical transaction. 

A Customer/Participant 12 enters an electronic storefront 
14 and is presented with the store*s EYoduct Database 116 in 
cormection with in-store sales, presented by the Sales Rep- 
resentative 114 together with an Incentives Subsystem 160 
and narrowcast advertising targeted at tiie Customer through 
a Promotions Subsystem 162 based on the Customer's 
demographics or purchasing habits as defined by a Partici- 
pant Subsystem 164 and Customer Accounts Subsystem 
117. 

In response, the Customer passes product or service 
selections to the Sales Rq>reseutative 114. The Sales Rep- 
resentative 114 obtains pricing information from the Incen- 
tives Subsystem 160 to get pricing rules, and then passing 
the selection list and the pricing rules to the Pricing Engine 
120, which calculates and returns discounted paces by 
matching the selection list against the pricing rules using 
product information from the I^oduct Database 116. 

The Sales Representative 114 then calls subsystems such 
as Tax Engine 122 to calculate Tax and Shipping. Thereafter, 
the Sales Representative 114 returns a total price to the 
Customer 12, who returns a final order to the Sales Rei«-e- 
sentative. 

Thereafter, the Sales Representative 114 arranges for 
Payment This includes querying the Customer for a pay- 
ment method (e.g., VISA card) and a means of authenticat- 
ing the identity of the Customer (c.g., a password); querying 
the Participant Subsystem 164 for payment information 
corresponding to the payment method (e.g., looking up tiie 
customer's VISA card number, which is secure from the 
store); calling a Payment Handler 126 to validate the pass- 
word and to authorize the credit transaction with an extomal 
payment network (not shown), e.g., VISAnet 

Next, fee Sales Representative 114 transmits the order to 
the Order Fulfillment Subsystem 128. Order Fulfillment 
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Subsystem provides Sales Representative 114 with a receipt 
to be placed in the Participant Brogram Object 112 as an 
indication that the order has been processed; calls Order 
FulfUlment Legacy System 130 to arrange for delivery of 
goods to the customer; and calls Payment Handler Interface 5 
126 to settle the payment Ordex Fulfillment Legacy System 
130 also feeds back data to update the Participant Subsystem 
and the Store Sales database, part of Observation Subsystem 
168. 

10 

IMails of the Transaction 

The above reflects an overview of a typical transaction. To 
more fiilly understand and describe this transaction it is 
useful to divide it into its diree phases: 

(a) initiation of a shopping session; 

(b) selection of items to be purchased; and 

(c) conq)letion of (he shoppmg session. 

Each of these phases is described in greater detail below: 
(a) Initiation of Session 20 

FIG. 6 depicts the initiation of a shopping session using 
the system of the invention. 

When the Customer 12 "enters" a Storefront 14, Partici- 
pant Program Object 112 is retrieved from the Participant 
Subsystem and activated. Storefront 14 determines what ^ 
Distributor Objects 118 exist to distribute coupons that can 
be used by this storefront This may be accomplished, for 
exan^)le, through the use of a nameserver such as that 
specified by tiie CORBA Object Request BroloEa:: Storefront 
14 calls Sales Rq>resentative Factory 115, passing to it the ^ 
Particqwnt Program Object 112 and the list of Distributor 
Objects 118. 

Sales Representative Factory 115 is a spedal-puiposc 
program object whose purpose is to create, or "instantiate," 
a Sales RqMresentative Program Object 114. Sales Repre- 
sentative Factory 115 instantiates a Sales Reprcsentative 
Program Object 114 in response to a request from the 
Storefront 14. Once created, Sales Representative Program 
Objet^ 114 initializes itself. ^ 

Sales Representative E^ogram Object 114 obtains from 
Participant Program Object 112 any Coupons 119 that have 
been retained by Participant Program Object 112 from prior 
shopping sessions. Sales Representative Program Object 114 
also calls Distributor Program Objects 118 to obtain any 
additional Coiq>ons 119 that represent current sales in Store- 
front 14. 

After the Sales Representative Object 114 is aeated, it 
figuratively accompanies the customer through the store, 
provides pricing information, authorizes the purchase 
method (e.g., VISA), applies any ^licabie discounts (e.g., 
in-store price discounts or coupon-based price discounts), 
and conopletes the sale (e.g., ships the items and airanges fcs 
payment). In one embodiment of the invention, the Sales 
Representative Object 114 is dedicated to the Customer 12 ss 
until the Customer 12 completes that session but does not 
outlive a shopping session. In another embodiment of the 
invention, the Sales Representative Object 114 may span 
several sessicms. The life of Sales Representative Object 114 
is tenninated upon payment (or billing fr^uency), which is ^ 
specified by Store Management. For example, if biUing is 
per session, the Sales Representative Object 114 only lasts 
for that session; but if billing is monthly, the Sales Repre- 
sentative Object 114 lasts for the entire month. 

The call to the Sales Rep Factory 115 to create a Sales 65 
Rq)resentative Object 114 may be coded using the CORBA 
Interface Definition Language (IDL) as follows: 
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interfece B V_SalcsRep Fac { 

BV_SalMRep cwat«LJrep ( 

m BVPaiticipant jvart, 

in BV^Ioccntiv&DistiibutorList dl, 

); 
}; 



Here, a function create_srep of type BV_SalesRep 
receives two inputs: part, of type BV_Participant (and 
identifyhig Participant Program Object 112); and dl, of type 
BV_IhcentiveDistribut(BrIJst describing a list of Distributor 
Program Objects 118. 

The first input, part is infcamation on the customer's 
household transmitted from Participant Subsystem 164 to 
Sales Representative Object 114. The second input, dl, is a 
list of all currently available Incentive Distributors associ- 
ated with the store. 

Following initialization of Sales Representative Program 
Object 114, the Sales Representative Factory 115 passes a 
pointer to the Participant Program Object 112 to the Sales 
Representative Object 114. The pointer is a data area that 
indicates where its corresponding program object can be 
found. Thus conmuinications between the Participant Object 
112 and the Sales Rqiresentative Program Object 114 can be 
established. 

In a siinple nondistributed iiiq>lementation, the pointer 
may simply be an address of the location in the computer's 
storage at which the program object to which the pointer 
corresponds may bt found. 

In more complex inq)lementations, such as an implemen- 
tation capable of t)eing distributed across multiple con^)Utcr 
platforms, the pointer may be an object handle in the form 
of a token that can serve as input to an object request broker 
such as a CORBA-compliant ORB. Based upon the contents 
of a particular object handle, the ORB can then direct a 
request to use the services of a particular program object to 
that program object 
(b) lYansaction Processing 

Once the Sales Representative Object 114 is instantiated 
the customer may select item for purchase. FIG. 7 depicts 
the process by which a customer does so. User Interface 13 
presents the customer 12 with descriptions of items for 
potential purchase using any means capable of being 
enq)loyed by the User Interface 13. For example, a full- 
screen interactive system such as an onHne service or a 
WWW session may employ icons associated with various 
products and services, whereas an interactive cable televi- 
sion service may employ a product list that can be scrolled 
and from which items may be selected using buttons on a 
remote control device. 

When the customer 12 selects items for purchase. User 
Interface 13 calls Sales Representative Program Object 114 
to inform that program object of the selected item. Sales 
Representative Program Object 114 maintains a Purchase 
list 170. In response to requests from User Interface 13 to 
select an item. Sales Representative Ptogram Object 114 
validates the selected item against Product Database 116 and 
adds the selected item to the Purchase list 170. 

This is done using a call diat interrogates the Product 
Database 116 for Product Data consisting of an item descrip- 
tion and its Ust price at the time of selection. 

The selection of an item for purchase is not a commitment 
to purchase. It is analogous to a shopper placing an item in 
a shopping cart in preparation for a purchase. Jfust as a 
shq>per may elect not to purchase a selected item, User 
Interface 13 may also communicate to Sales Representative 
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Program Object 114 that the customer docs not wish to of the mother of the household, the token might contain the 

purchase an item that has previously been selected. In string "Mom's Visa,** 

response to such a call, Sales Representative Rrogram (ii) Selection of Payment Method 

Object 114 removes the corresponding entry from Purdiase in response to ou^ut from the function call given directly 

list 170, 5 above, and as shown in Stqi 181, Sales Representative 

Sales Representative Program Object 114 validates all Program Object 114 calls User Interface 13 to obtam the 

applicable coupons against the store's Redemption Database customer's selected method of payment As shown in detail 

172 (which is part of Incentive Subsystem 160) and obtains ^ pjQ ^gj Representative Program Object 

the pricing rules fcr the incentive programs that those 114 calls User Interface 13, passing to it the list of payment 

coupons represent The Redemption Database 172 accom- method tokens that correspond to the payment methods for 

pushes this by referencing the incentive programs reoHrded customer is authorized. User Interface 13 presents 

in the Redemption Database 172 and referencing the {fficing customer, for selection of a preferred payment 

rules from the corresponding Incentive Program Objects. jj^ethodandtheprovision ofa password necessary to authen- 

OptionaUy, during the course of selectmg items for ^cate his or her use ofthe payment method The informaaon 

purchase, Sales Representative Program C^ject 114 may call presented to die customer 12 is described below in greater 

Pricing Engine 120 to determine the total cost of die Ucms reference to FIG. 9. User Interface 13 conqwtes 

currenUy selected and placed on Purchase list 170. Sales ^ payment authorization token, called the Response to 

Representative Program Object 114 passes the purchase Ust chaHenge, and provides it to Sales Rcfffesentative Program 

and any appUcable pricing rules to Pnang Engme 120. ^^.^ Response to Challenge is an encrypted 

Pricing Engine 120 obtains additional item attnbutes from ^ ^^^^ ^^^^ password entered by the user. 

Product Database 116 and calculates the proposed total cost , Validation 

of the selected items with discounts from zppUcMe incen- ^ response to ou^ut from the function call above, 

tives via die pricing rules. . o , t> the payment method selected and the passwOTd entered by 

This total cost informaUon is returned to Sales Ret^esen- customer 12 will be vaHdated. In step 182, Sales Rep- 

tative Program Object U4. Sales RepresentaUve Rrogram ^esentatlve Program Object 114 receives the method of 

Object 114 provides this information to User Interface 13, payment selection and the payment authorization token from 

which disi^ays it to the customer for approval or for further usq. interface 13. In step 183, Sales Representative Program 

item selection and/ci deselection. This price calculaUon may ^^.^ ^ Payment Handle Interface 124 to vaUdate 

be performed, for exan^le, after every selcctLon/deseledion ^j^^ ^j^^^^ payment, passing to the Payment 

operation initiated by the customer, or m response to the Handier Interface 124 the daU received from the customer 

customer's specific request to generate a current total ^ ^g^^ 

Thereafter, the transaction can be completed. ^* ^j^.^^ jg3 ^ performed by 

(c) Transaction CQnq)letion Payment Handler Interface 124 and Participant Program 

FIGS, 8, 8A and 8B depict the completion of an online ^^.^ ^ Payment Handler Interface 124 
transactioninthecoininfircesystem.Transactioncomplcton obtains the Response to ChaUenge token that was supplied 
is perf<Hmed by Sales Representative Program Object 114 m Typically, this will be passed by tiie Sales 
conjunction with Payment Handler Interface 124, as shown Representative Program Object 114 in the call to Payment 
in no. 8. FIG. 8A depicts the 5tq>s performed by die Sales Interface 124 in step 183. Payment Handler Inter- 
Representative Progiam Object 114 and FIG. 8B depicts the ^^4 calls Participant Program Object 112, passing to it 
steps performed by Payment Hanto Interface 124 m^ ^ Response to ChaUenge token. Participant Program 
junction with Participant Program Object 112. HGS. 8A and ^^.^ calculates, in Stqp 183C, a reference pay- 
SB and should be referenced in conjunction with HG. 8, ^^^^ authoization token. The reference payment authori- 
(i) Obtaining Payment Alternatives ^^^j^^ ^ encrypted token based upon the password 

In Step 180, Sales Repr^entative Program Object 114 Partidpant Program Object 112. In step 

calls Participant Program Object 112 to obtam a hst of Participant Program Object 112 compares tiie 

ractiiods of payment that are available to toe customer. In to Challenge token received from User Interface 

response to the call, Participant Program Object 112 passes ^3 reference payment authorization token, to vaH- 

to Sales Representative Program Object 114 a list of all authority of tixe customer to use the selected 

payment methods that the customer is authorized to use. payment method. If the two tokens are equal, Participant 

The call may be in^>lemented with the followmg code: ^ program Object 112 provides to the Payment Handler Inter- 

face 124 the information needed to effect an authorization to 

voidpreiaie_to_biQr( charge tiie selected payment method; generally tiiis will 

out BV_JaymfntMoT^<^-Piq™«iffj&t alias list, indude an account number, expiration date, cardholder 

out BV_Seciirity::UseiChaUeage cbaUenge) name, and the like. 

raises (BV^jnraiidState); 55 In Step 183F, Payment Handler Interface 124 verifies tiiat 

— — — Ijjg Participant Program Object has successfully verified the 

Parameters alias_Jist and challenge are ou^uts from tiie Response to Challenge. If so, in Step 183H, the Payment 

function. Handler Interface 124 calls External Payment Handla* 126 

For each payment method, (he Participant Program Object to obtain an authorization to charge. External Payment 

112 provides tiie Sales Representative Program Object 114 60 Handler 126 is typically a computer system operated by tiie 

witti a short token used to describe the payment metiiod and institution suppiiting tiie payment mctiiod. For example, if 

a challenge tiiat will be used to validate attempts to use tiie the customer selects a Visa credit card as a payment method, 

payment metiiod. The token is a text string tiiat identifies tiie then Payment Handler Interface 124 will call tiie VKAnet 

payment method using words that are familiar to the system for autiiorization to charge tiie selected Visa account 

customer, but does not contain any confidential information. 65 Extanal Payment Handler 126 notifies Payment Handler 

For example, if a customer is autiiorized for a payment Interface 124 that the charge to the selected payment metiiod 

method using the ^a credit card account held in the name wiU be accepted* 
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If the tokens are not equal, Payment Handler Interface 124 
in step 183G sets an indicatGr that the selected payment 
method was not properly authorized. Following either step 
183G or 183H, Payment Handler Interface 124 in step 1831 
returns control to Sales Representative Program Object 114. 
Typically, in this step Payment Handler Interface 124 may 
indicate success by supplying to Sales Representative Pro- 
gram Object 114 an Authorization Object that describes the 
authorization to charge. 

In step 184, Sales Representative Program Object 184 
checks whether Payment Handler indicated that the selected 
payment method was not properly authorized. If it was not 
authorized, Sales Representative Program Object 114 
returns to step 181 to again prompt tiie customer to reenter 
the method-of-payment data, or optionally aborts the trans- 
action. 

One benefit of this method is that it avoids the transmis- 
sion of sensitive information such as credit card account 
numbers to Sales Representative ftogram Object 114. No 
account numbers are transmitted between User Interface 113 
and Sales Representative Program Object 114, 

(iv) Order Fulfillment 

Once authorization to cfaaige been effected, and as shown 
by Step 185, Sales Representative Program Object 114 calls 
die Order Fulfillment Subsystem 128, providing it with the 25 
list of items ordered by tiie customer. Order Fulfillment 
Subsystem 128 typically calls an existing Order Fulfillment 
Legacy System 130 to generate shipping manifests and 
perform other activities needed to ship the selected products 
to the customer. 

(v) Generating Receipt 
Following step 185, Sales Representative I^ogram Object 

114 creates a receipt 192 and passes it to Participant Program 
Object 112 for storage to be used if later verification of the 
order is required. 

lypically, the step of creating the Receipt 192 may be 
accomplished by the steps shown in FIG. 8A. In st^ 186, 
Sales Representative Program Object 114 replicates Pur- 
chase List 170. In Step 187, Sales Representative Program 
Object 114 then modifies the replicated Purchase List 170, ^ 
to indicate that the resulting data structure is a receipt, e.g., 
by setting a flag. In Step 188, Sales Representative EYogram 
Object 114 calls Participant EVogram Object 112, passing it 
the newly created receipt 192 for storage. 

(vi) Settlement 
When the selected products are indicated as shipped. 

Order Fulfillment Subsystem 128 calls Payment Handler 
Interface 124 to request the payment that previously autho- 
rized in step 183D. Payment Handler Interface 124 again 
calls External Payment Handler 126 to convert the auttiod- 
zation to charge to a payment order. 

(vii) lQ]^lementation of Sections (iii) to (vi) 
The components of the transactLon described above under 

Sections (iii) to (vi) are completed by the following calls 
which are described in detail below. 

Once the customer 12 has selected a choice of payment 
type, the Sales Representative Object 114 then calls a buying 
fiinction of the form: 
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BV_Reoeipt buy ( 

in BV_PayiDeiitMcMutDr:i*aymentAl^ pflyment^lype, 
in BV__PgymentMonitor.:UserNainp usa; 
in BV_Securi^::UseTRefl|>anse tesponse, 
in BV_BooIean extBina]_p^mcnt_jnethod, 
in BV Payxncnfl^fhod cpm 
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-continued 



< 

BV_CtcditAuth, 

BV_ShiFpipgCalc, 

BV_JPricingCalc, 

BV_Jl.odcmptiDn, 

BV_JPulfilliDent, 

BV_Abort, 

BV_JavaEtiState 



This call perftsms a number of steps including: 

(i) creating an invoice listing the items to be bought and 
the shipping destination, 

(ii) calling the Pricing Engine 120 to calculate a subtotal, 

(iii) calling the Order Rilfillment Subsystem 130, 

(iv) calling the Tax Engine 122, 

(v) computing the total price for the order, 

(vi) authorizing payment for the order, 

(vii) fulfilling the order, 
(viuL) redeeming coupons, 

(ix) returning unused coupons to tiie customer, and 

(x) creating a receipt for the customer. 
These stq>s are discussed in turn, below. 

The first step is a call to the Pricing Engine 120 to 
compute a subtotal for the items in the customer's order. The 
Sales Representative Object 114 passes the customer's order 
and all the currently existing Pricing Rules to the Pricing 
Engine 120, which returns a Total list Price, a Total Dis- 
count and an itemized price list 

The actual interface to the Pricing Engine 120 takes the 
form: 



35 



BV., _>TTiffTiHTTwnfT .is.t eval( 

in BV__ltemList taxgeOtems, 
in BV_J[ten3List basIceL_ftenis, 
in BV_JiQcentivdLisLJncentives; 
out BV__Money totaLJist_Frice, 
out BV_Miraiey totaL_discount 

); 



35 



The first two inputs, target_items and basket_jtems, 
together comprise tiie Customer's order. Target items are 
those items that are discountable. Basket^tems are those 
items that are nondiscountable, but which may be required 
to support discounting (e.g., they may contribute to meeting 
a quantity requirement). 

The third input, incentives, is a list of all currently existing 
store incentives. Each Incentive takes the form: 



stmct BV_jQcentivc ( 

long applicatton-joount; 
boolean vaUcL^wittL-Otheis; 
BV_^PticiqgRiik rule; 

): 



) 



where applicatioiL-COunt is the number of times the dis- 
count may be applied; 

valid_witii__others is TRUE if the coupon can be applied to 
items already subject to a pricing change and FALSE 
otherwise; and 

rule is the pricing rule defined by the Store Management via 
the Store Management Dashboard 20 (as discussed below). 

The conc^arison of items to predicates (described in detail 
below with reference to FIG. 11) uses a pricing algorithm as 
follows: 
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Set the totaL_list_price to $OjOO 
Set tie totaL-discouot Co $OjOO 
For each item in target_iteiDs: 

Add the item's list price to the totaLJist_pnce 

If the item is no longer discountable, continue to next item 

For each iuoestive: 

If the rale matches and yields an adjustment, then Store the <item, incentive, rule, at$ustmcn)> 

quaitet in an amy of results 

hiark. item no bnger discountable if the incentive is not valid with other offers 
If the adjustment is an amount, modify the totaL_discount aocoidiqgly 

Eodif 

End this incentive; process next incentive in sequence 
Return the array of results to the Sales Rep. 



After computing the totaLJist-price and totaL-discount, 
tbe Sales Representative Object 114 invokes a subtotal 
function to calculate the subtotal=total_Jist_price-total_ 
discount The Sales Representative Object 114 then invokes 
a shippin g c ost function to pass the order to an external 
Shipping Subsystem that calculates shipping costs. This is 
typically one of several existing legacy systems which 
interface to the electronic store throu^ the electronic mall's 
Shipping APL Similarly^ the Sales Representative Object 
114 calls an external Tax Subsystem to calculate the taxes. 
Sales Representative Object 114 then adds the subtotal, 
shipping, and tax to give a total price. 

The next step is to authorize payment, as described above 
in detail. After the sale is authorized, any coupons 119 that 
were actually used can be redeemed (as will be described 
below). Any unused coupons 119 are released back to the 
Sales Representative Object 114 to be returned to the 
Participant I^ogram Object 112 within Participant Sub- 
system 164. Such coupons will be available for use by the 
customer in subsequent shopping sessions, 
(viii) User Interface for Payment Selection 

FIG. 9 depicts one example of a User Interface 13 to select 
the preferred payment method as required by the system to 
the complete the transaction along the lines describod above. 

In the example, User Interface 13 displays a screen image 
113. The screen image includes a display of payment options 
212. The customer 12 (not shown) is presented with three 
payment options: 1) 'Mom's Visa"; 2) "Jim's AMEX"; 3) 
"Debit Jim's Checking Account." User Interface 13 also 
provides a means for the customer to indicate his or her 
selection of payment methods. This means is depicted as 
selection input area 214. The customer may, for exano^le, 
type the number corresponding to the selected method of 
payment in this position. 

In addition. User Interface 13 provides a means for the 
customer to supply a password to authenticate his or her 
identity and authority to use the selected payment method 
In the exanq)le, this means is depicted as password entry 
area 216. The customer may eater a password at that location 
on the screen. User Interface 13 then computes a payment 
authorization token using the password, and transmits the 
method of payment selection and the payment authorization 
token to Sales Representative Program Object 114. 
V. Storefront Setup Overview 

Each electronic store (represented by storefront 14) has a 
Store Management associated with it Tbe Store Manage- 
ment interacts with the electronic store through a Store 
Managemoent Dashboard 20, which is typically a grs^hical 
user interface running at a store manager's local personal 
coDoputer. These interactions include interactions with 1) the 
Incentive Subsystem 160 to create discount programs, 2) the 
Order Fulfillment subsystem to con&gure or monitor the 
ordering process, 3) the Observations Subsystem 168 to 



monitor store sales data, and 4) the Participant Subsystem 
164 (owned by service provider) and Customer Account 
Subsystem 117 (owned by store) to collect customer usage 
data. Of these, Item 1, incentive creation, which relates 
mostly to pre-sales activity, is discussed here. 
Creating Incentives 

In overview, and as shown in FIG. 10, the Store Man- 
agement uses Store Management Dashboard 20 to interface 
with the Incentives Subsystem 160 to create Incentive 
Programs 250. 

Information speciiied in creating an Incentive Program 
250 would include the name and description of the incentive, 
its starting and ending dates, its sponsor, and the price 
discount Incentive Programs 250 are created independently 
of actual shopping sessions, although they may also be 
created while customers are shopping in the store. 

Incentive I^ograms 250 might include: in-store (public) 
price discounts, coupon-based price discounts, point-based 
frequent buyer discounts, or quantity discount cards. 

The function of these incentive programs 250 invention 
will first be described with reference to FIGS. 11 to 13 and 
in the context of in-store price discounts, which are the most 
common type of incentive. Thereafter the coupon-based 
price incentive wiU be discussed as an extension to the 
general framework established by the discussion of in-store 
price discounts. Frequent buyer discounts and quantity dis- 
count cards are discussed, 
(i) In-Store Price Discounts 

In-store price discounts are those where a customer need 
not present a coupon to obtain the price discount, and which 
is contingent only upon the customer being in the store while 
the incentive program is being offered. These are analogous 
to publicly advertised weekly sales in a physical store. 

Although in-store sales are couponless from the custom- 
er's persi)ective, it will be convenient, from the architec- 
ture's perspective, to think of in-store price discounts as 
resulting from coupons that are distributed to the customer 
upon entering the store. That is, the customer need not bring 
coiq)ons, but is automatically entitled to &e appropriate 
coupons for any in-store sales. The coupon is used to inform 
the customer of all in-store price discounts in effect on 
entering the electronic store — analogous to handing a sales 
flyer to a customer entering a physical store. This wiU be 
explained in detail in the discussion of an actual shopping 
session below. The concept of a coupon for in-store price 
discounts is also useful because it establishes an incentive 
framework that can be used for true coupon-based price 
discounts (where the customer must present a coupon to 
receive the price discount), discussed below. 

Ih-store price discounts are embodied in Incentive Pro- 
grams 250 created by an Incentives Subsystem 160, as 
shown in FIG. 10. Each Incentive is expressed in a Itidng 
Rule of the form: 
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stnict BV_pricn^gRule ( 
kag applkatioi]..pouat; 
boofeac valkL.witlL_olliBis; 
By_A4iustmentAiidPredic&te lule; 

); 



where applicatioD_couDt is the number of dmes the dis- 
coant may be appHed; 

valid_with_others is TRUE if the incentive can be ^plied 
to items abready subject to a pricing change and FALSE 
otherwise; and rule contains the Adjustment and Predicates 
associated with the incentive: 



stnict BV_J^justiaentandftedicate ( 
BV_Jlc^ii£tmexit adjustment; 
BV_fMicatcUst predicates; 

); 



Each Pddng Rule is embodied in a Pricing Rule Stcuctuic 
260, illustrated in HG. 11. Pricing Rule Structure 260 
typically conq>rises three data segments. These axe an 
Adjustment Segment 262, a Predicate Segment 264, and a 
Qualifier Segment 266. Each Pricing Rule Structure 260 
includes one Adjustment Segment 262 and at least one of a 
{dedicate Segment 264 and/or a Qualifier Segment 266. 
Each is discussed in detail below: 
(a) Adjustment Segments 

An Adjustment Segment 262 describes how the price of 
an item is affected if all Predicates Segments 264 (described 
below) arc matched. The Adjustment 262 may be either a 
single adjustment or a quantity adjustment A single adjust- 
ment may either be fixed (e.g., sale price is $10), absolute 
(e.g., $10 off), or percentage (e.g., 10% off). A quantity 
adjustment includes the price-based discounting of a simple 
adjustment but also allows for quantity-based discounting. It 
takes the form: 



stzucrt BV_QuantityA($u5tmeiit ( 
unsigned sfaoit tequiied; 
unsigiocd short discouated; 
BV_SiinpleAdjustineat a(^j^lstInm^, 
boolean lesfL-OiL_equal; 



where required is the minimum purchase requirement, dis- 
counted is the number of items discounted by this rule, 
adjustment is the simple adjustment, and less_or_equal= 
TRUE if the discounted items must be less or equal in value 
to the items making up the minimum purchase requirement. 

Thus, Adjustment Segment 262 contains at least two 
fields, which respectively indicate the type and amount of 
adjustment to be made to a price of an item. An Adjustment 
262 may be of a type None, Fixed, Absolute, or Percentage. 
The use of the amount field is dependent on the value of the 
type field. If Adjustment 262 is of type *'None,'* no adjust- 
ment will be made to the price of an item at time of purchase: 
the item will be sold at the price indicated in Product 
Database 116. 

If Adjustment 262 is of type ^Tixed,** the amount field 
contains a value to be substituted for the price indicated in 
lYoduct Database 116. For exan^le, if the amount field 
contains **20,'' the price of the item will be $20, regardless 
of the value in Product Database 116. 

If Adjustment 262 is of type "Absolute,** the amount field 
contains a value to be deducted from the price indicated in 
I^oduct Database 116. For example, if the amount field 
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contains "20,** $20 will be deducted from tfie value indicated 
in Pricing Database 116. 

If Adjustment 262 is of type '"Percentage,** the amount 
field contains a value, expressed as a pacentage, that is to 
5 be deducted firom the price indicated in Product Database 
116. For example, if the amount field contains '^O,** then the 
value indicated in Pricing Database 116 will be reduced by 
20 percent 

(b) Predicate Segments 

10 A Predicate Segment 264 is a specified condition an item 

must meet to qualify for the adjustment 
Predicate Segment 264 also contains at least two fields, 

respectively a type field that indicates the type of test that is 

used to detomine whether the pricing rule may be applied 
15 to a given item at a given time, and a conditions field that the 

conditions that must be satisfied in order for tiie pricing rule 

to be applied. 

If Predicate 264 is of type *Time of Day,** the conditions 
field contains two values, which indicate the beginning time 

20 of day and the end time of day that delimit a period of time 
on which the pricing rule may be applied. For example, if the 
conditions field contains the two values corresponding to 
times of day "17:00:00" and **21:00:00,*' thepridngrule wiU 
be applied only between 5.-00 P.M. and 9:00 P.M. 

25 If Predicate 264 is of type "Date,** the conditions field 
contains two values, which indicate the beginning and end 
dates on which the pricing rule may be applied. For exan^le, 
if the conditions field contains the two values corresponding 
to the dates "Jul. 1, 1996'* and "JuL 31, 1996,** then the 

30 pricing rule will be appHed only during the month of July 
1996. 

If Predicate 264 is of type "Day,** the conditions field 
includes a seven-entry boolean array, each entry of which 
corresponds to a particular day of the week. A "1** value in 

35 an entry indicates that the pricing rule may be applied on the 
day to which the entry cocresponds; a **0*' value indicates 
that the pricing rule is not to be applied on that day. For 
example, if the conditions field contains the value 
"0000011,** then the {ridng rule will be applied only on 

40 Saturdays and Sundays. 

If Predicate 264 is of type *ltem Identifier,** the conditions 
field contains a list containing one or more values that 
identify one or more items to which the pricing rule may be 
applied. For exan^)le, if the conditions field contains the 

45 value '•XGa>-100-56,** the pricing rule will be applied only 
to purchases of the item identified in Product Database 116 
as "XCD-100-56.** 

If Predicate 264 is of type **Item Attribute,** the conditions 
field contains a list containing one or more values that 

50 identify an attribute of one or more items to which the 
pricing rule may be ^plied. For example, if the conditions 
field contains &e value "blouse," then the pricing rule will 
be applied to all items identified in Product Database 116 as 
having the attribute "blouse.** 

55 If Predicate 264 is of type *'Frice,** the conditions field 
contains a comparator indicator having a value such as 
"'greater than,** "less tiian,** etc., and a con^^arison value to 
be compared to the item*s price. For example, if the condi- 
tions field contains a comparator value of "greater than** and 

60 a ccHnparison value of "10,** the pricing rule will be applied 
to all items identified in the Product Database 116 as having 
a price greater than $10. 

(c) Qualifier Segments 

(Jualifier Segment 266 is used to identify additional 
65 discounts that may be applied other than on an item-by-item 
basis. For example, a Qualifier Segment 266 may be used to 
indicate that tiie pricing rule is to be implied only if 5 or uK^e 
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items are purchased, if the transaction is for over $100 worth 
of items, or to indicate that one product may be obtained at 
no charge with the purchase of a particular second product 
(ii) Coupon-Based Price Discounts 

In contrast to the Price discounts described above, 5 
coupon-based price discounts are those where a customer 
must present a coupon in order to obtain a specified price 
discount in a present shopping session. Coupons may come 
from previous shopping sessions in the coupon-accepting 
store (intra-store marketing), or from previous shopping lo 
sessions in other stores or from a manufacturer supplying 
many stores (inter-store marketing). 

The same incentive creation mechanism discussed above 
for in-store price discounts is used to create coupon-based 
price discounts, which may be treated as a superset of 15 
in-store price discounts. The primary difference is that the 
fields for total numbers of coupons and starting serial 
number arc now significant, for they are tools by which stOTe 
management can limit coupon offerings and track coupon 
redemptions. 20 

Specifically, coupons other than in-store sale coupons are 
persistentiy retained in Participant f^ogram Object 112 firom 
session to session, rather than being available only in the 
particular session and storefront in which the coupons were 
distributed. A coupon contains the same information as 25 
in-store sale coupons as depicted, namely, the applicable 
Adjustment Segments 262, Predicate Segments 264, and 
Qualifier Segments 266. In addition, such coupons also 
contain a serial number and a digital signature. The serial 
number is an aibitraxily-sized numeric field that is unique for 30 
every coupcm distributed by a Distributor Object, within a 
range as specified at the time the Incentive Program that 
produced the coupon was created. When a coupon is 
redeemed, an entry for that coupon is made in Redemption 
Database 172, indicating that the specific coupon with the 3S 
specific serial number has been redeemed. A coupon with a 
given serial number will only be redeemed if the Redemp- 
tion Database does not contain an indicates' that the coupon 
has already been redeemed. This prevents a coupon firom 
being copied and used by more than one customer, and from ao 
being reused by the same customer more than one time. 

To maintain the integrity of the coupon's contents, the 
coupon also contains a digital signature. The digital signa- 
ture is a field whose content is the result of a cryptographic 
operation using, for example, the public key encryption 45 
method of RSA Data Security, Inc.. The cryptographic 
operation operates on the contents of the remainder of the 
coupon, using a key to yield a digital signature, which is 
stored in the coupon. With the digital signature, any modi- 
fication of the coupon will fail the redemption process when 50 
the digital signature is compared to the remainder of the 
coupon. This prevents, for example, a customer from alter- 
ing a discount field to obtain a discount that is greater than 
that offered by the storefront. It also prevents a customer 
from making a copy of a coupon and changing its serial 55 
number so that it can be used in addition to the original 
coupon. 

Dashboard Operation 

As indicated above. Store Management interacts with the 
system through a Dashboard 20, typically hardware with an 60 
associated display saeen. Associated witii Dashboard 20 
and as shown in FIG. 12, is a Dashboard Client 280, in the 
form of software. As illustrated in FIGS. 12A and 12B the 
Dashboard Client 280 causes certain information to be 
displayed on die screen of the Dashboard 20. In order to 65 
better understand the operation of the Dashboard Qient, 
these three Figures should be referenced together. 
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FIG. 12A depicts one view presented by the Dashboard 
Client to storefront management. Specifically, FIG. 12A 
depicts a storefront manager establishing an Adjustment 262 
of type ••Percentage," indicating a 20% discount Dashboard 
Client 280 displays a Pricing Term Details Window 282. 
Pricing Term Details Window 282 includes a set of buttons 
284 that are used to select the type of Adjustment 262 being 
defined, and a set of input areas 286 that are used to specify 
the amount of discount to be applied. 

FIG. 12B depicts a second view presented by the Dash- 
board Client 280 to a storefront manager. Specifically, FIG. 
12B depicts a storefront operator establishing a Predicate 
264 of type ••Date" tiiat is valid from Jul. 1, 1996 until Jul. 
31, 1996, and a Predicate 264 of type •'Day" that is valid 
only on Saturday and Sunday. Dashboard CUent 280 dis- 
plays Sales Details ^ndow 288. Sales Details Window 288 
includes a set of two input areas 290 to specify the beginning 
and end dates on which this pricing rule may be applied, and 
a set of Day-of-the-Week buttons 292 that indicate the days 
on which the pricing rule may be applied. 

Referring now to FIGS. 12, 12A and 12B together, at the 
control of the storefront manager and responsive to the data 
input by the storefront manager, Dashboard Client 280 
creates Pridng Rule Structure 300. Thereafter, Dashboard 
Client 280 calls Incentive Factory 302, passing it Pricing 
Rule Structure 300. Incentive Fact(Hy 302 creates Incentive 
Program Object 160 reflecting the contents of Pricing Rule 
Structure 300. Dashboard Client 280 then calls Distributor 
Factory 304, passing it as a parameter Incentive Program 
Object 160. Distribute Factory 304 creates Distributor 
Program Object 118. As described before, Distributor Pro- 
gram Object 118 will be made available to Storefronts 14, 
and will provide Storefronts 14 with Coupons 119 at trans- 
action time. 

Dashboard Client 280 then calls Reden^ition Registry 
310, passing to it as a parameter Incentive Program Object 
160. Redemption Registry 310 records Incentive Program 
Object 160 in Redemption Database 170. As will be recalled 
and as described with reference to FIG. 7, Redemption 
Database 170 wiU be used by Sales Representative Program 
Object 114 to validate any Coupons 119 sought to be applied 
to a transaction. 

FIG. 13 dq)icts the operation of Pricing Engine 120 in 
applying Coupons 119. In Step 300, Pricing Engine 120 
begins processing the Purchase List 170 and the associated 
Coupons 119. 

In Step 304, Pricing Engine 120 checks whether it has 
been passed any Coupons 119. If there are no Coupons 119 
to be applied, Itidng Engine 120 skips processing of 
incentives and proceeds to Step 306. 

But, should any Coupons 119 apply, and as shown in Step 
308, Pricing Engine 120 selects the first of the Coi^ons 119 
for processing. In Step 310, Pricing Engine 120 selects tiie 
first of the Predicate Segments 67 in the Coupon selected. In 
Stq> 312, Pricing Engine 120 evaluates the selected Predi- 
cate Segment 264 to see if it applies to any of the products 
specified in Purchase List 170. In Step 314, if conditions 
specified in the Predicate Segment 264 are not met. Pricing 
Engine 120 skips to Step 316 without ^plying the incentive. 
If the conditions specified in the Predicate Segment 264 are 
met, Mdng Engine 120 in Step 318 checks whether there 
are further Predicates to be tested. If so, Pricing Engine 120 
in Step 320 selects the next Predicate Segment to be tested, 
and repeats from Step 312. 

If all Predicates have been satisfied, in Step 322, Pricing 
Engine 120 applies the Coupon's Adjustment Segment 262 
to the price <k the item as obtained from Product Database 
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116, i.e.» by applying a new price for this transaction (for an 
Adjustment of type 'Tixed"), by reducing the price by the 
dollar amount indicated (for an Adjustment of type 
"Absolute"), or by reducing the price by the percentage 
indicated (for an Adjustment of tj^e **Pcrcentage"). 

In Step 316, Pricing Engine 120 diecks whether there are 
further Coupons 119 to be processed, more Coupons 119 
remain to be processed. Pricing Engine 120 in Step 324 
selects the next Coupon to be processed and returns to Step 
310 to begin processing of the newly selected Coupon. If the 
last Incentive Program Object has been processed, Pddng 
Engine 120 proceeds to Step 326. In Step 326, Pricing 
Engine 120 computes the total cost of the transaction, with 
all Coupons 119 applied to Purdiase Ust 170. In Stq> 328, 
Ricing Engine 120 returns control to Sales Representative 
Program Object 114. 
Observation Subsystem 

The Observations Subsystem 168 (FIG. 5) provides a 
system for recording events that represent observable data 
that results from customer interactions. FIGS. 14 and 15 
depict the Observation Subsystem 168. Observation Sub- 
system 168 con^xrises two t^s of program object. These 
are called collectors and event recipients. FIGS. 14 and 15 
depict three coUectcrs 340, 342 and 344 and four event 
recipients 350, 352, 354 and 356. A program object called a 
"collector^ communicates events to one or moie event 
recipients that have registered with the ccUector. Event 
Recipients are of two types, either Active Monitors ca: 
Loggers. 

Active Monitors poform real-time analysis of observa- 
tions. Each Active Monitor analyses certain types of data to 
produce a result that can be displayed to a store operator via 
the Dashboard. An example is an Active Monitor for moni- 
toring sales volume. Such an Active Monitor could receive 
events that describe orders purchased, and calculate a peri- 
odic total of items being purchased. The result would be a 
tracking of volume of orders on aperiodic basis, e.g., hourly, 
which could be presented as a graf^iical display on the 
Dashboard. 

Loggers receive observations and write them to an exter- 
nal file in a predefined format, to produce a log of events tiiat 
can be subsequently processed for historical analysis. For 
exanQ)Ie, the log could be processed to determine if there is 
a trend signifying an increase over time of purchase of 
selected items. Also, purchases over time may be correlated 
with specific attributes of customers, e.g., income level or 
neighborhood. The resulting information could be provided 
to the Promotions Subsystem 116 to direct particular pro- 
motions to customers having similar attributes. 

FIG. 14 depicts the process of reg^tration with a collec- 
tor. An Event Rec^)ient such as Event Recipient 350 locates 
a Collector such as Collectc»' 340 by means of a nameserver 
such as that specified by &e CORBA Object Request Broker 
specification. Event Recipient 350 makes a call 360 to 
CoUectpr 340, requesting to be registered with Collectcr 
340. FIG. 14 depicts Event Recipient 350 registering with 
Collector 340; Event Recipient 352 registering with CcUeo- 
tors 340 and 342; Event 354 registering with Collector 344; 
and Event Recipient 356 registering with Collector 342. As 
can be seen in FIG. 14, an Event Recq)ient may be registered 
with more than one Collector, and a Collector may register 
more than one Event Recipient 

FIG. 15 dq)icts the process of communicating Events 361 
from Collectors 340, 342, and 344 to Event Recipients 350, 
352, 354 and 356. Eaxh Collector communicates events only 
to the Event Recipients that have registered with it 

Events that are transmitted by a collector may include 
events tracking general system navigation events, shopping 
events, purchasing events, and user-defined events. 
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(jeneral system navigation events may include, for 
example: Start-Session, End_Session, GenericJProfile, 
Enter^ervice, Exit_Service, Enter_Category, Exit_ 
Category, Enter_Xocation and Exit__Location. 

3 The Start_^ssion event defines when a customer begins 
a particular commerce session. This may be, for example, 
when the customer logs on to Compuserve, America Online, 
etc. This event includes the following data: session^d, an 
unique identifier identifying the session; session. 

10 connection, which identifies how the customer is connected 
to the session; and date__time, a dateAime stamp. The 
End__Session event defines when a customer exits a par- 
ticular session. This event includes the date: session_Jd and 
date_time. 

15 The Generic_J^ofile event is optionally generated at 
session start time to provide the Observation Subsystem 
with information regarding the customer. This event 
includes the following data: income Jevel; gender; age; and 
geogr^hic location. 

20 The Enter_^Service event is generated when a customer 
begins using a particular storefront This event includes tfie 
following data: sessioiLjd; service^d, which identifies the 
particular storefront in use by the customer; and date_time. 
A corresponding Exit^JService event is generated when the 

25 customer leaves the storefront, and includes session_Jd; 
service_Jd, and date_time. 

The Ento-.Category event is generated when a customer 
selects a particular category of items to review within a 
storefront It includes the following data: session_Jd; 

30 service_Jd; date_timc; and catego(ry_Jd, whidi identifies 
the particular category being selected by the customer. A 
corresponding Exit_Category event is generated when the 
customer exits the category and includes session_Jd; 
service_id; date_time; and category_Jd. 

35 The Enter_J^ocation event is generated to identify physi- 
cal location information about items being reviewed by a 
customer, for example, a particular spot on a printed catalog 
being reviewed by a customer. It indudes the following data: 
sessioa_id; service_id; date__time; and location_id, which 

40 may, for example, identify the cartesian coordinates within 
a particular catalog page being reviewed by the customer. A 
corresponding Exit_JjOcation is generated when the cus- 
toma stops reviewing the physical location and includes the 
following data: session^d; service_id; date_time; and 

45 location^d. 

Shopping events may include, for example: Select_Item, 
Unselect_Jtem and 'N^ew.Jtem. 

The Select_Jitem event is generated when a customer 
selects an item as a purchase candidate, akin to when a 

50 customer in a real store places an item in a shopping cart 
The Select_J[tem event includes the following data: 
session_Jd; service_Jd; date_time; and product_Jd, which 
identifies the selected product. 
The Unsdect^Jtem event is generated when a customer 

55 decides not to purchase a particular item and unselects the 
item as a purchase candidate, alrin to removing it from the 
shopping cart and replacing it on the store shelf. The 

XJnselectJtem event includes the following data: session 

id; semce_Jd; date__time; and producLJd. 

60 The View_Xtem event is generated when a customer 
requests derailed information about an item t)eing offered by 
a storefront The View_]ftem event includes the following 
data: session__id; servicc_id; date_time; and product_Jd. 
Purchasing events may include, for exanqde: Purchase.. 

65 Item and Purchase_Qrder. 

The Purchase_Item event is generated when a customer 
actually purchases a selected item. When a purdiase request 
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is made, one Purchase_Jftem event is generated for each IL Coupon-Based Frequent Buyer Points 

item purchased. The Purchasc_Item event includes the A coupon-based pice frequent buyer program is one in 

following data: session^d; service_Jd; date_time; which the customer presents a coi^wn, typically from a 

product_id; retail_4)rice; discount_price; and incentive_ previous shopping session, for frequent buyer points in a 

name, whidb identifies any incentive that was applied to the 5 present shopping session. The frequent buyer coupon takes 

price. the same predicate/adjustment fonn as the price discount 

The Purchase_Qrder even is generated when a customs coupon, except that die adjustment takes the fom of points 

actually makes a purchase of one or more items. When a issued to a customer's frequent buyer account rather than an 

purchase request is made, one Purchase__Order event is instantaneous price discount. The customer may redeem 

generated for the entire order, regardless of the number of . ^ various levels to obtain actual price discounts, 

items in the order. The Purchase„Order event includes die ^ Quantity Discount Incentives 

foUowing data: session_id; service.id; <iate tune; a third type of incentive program is the quantity discount 

numbcr_of^tems_4)urchased; totaUpnce; and totaL ^^^^^ ^^^^^^ ^ ^^^^^^ ^^^^^j ^hi^h 

AuL-DefinedEventisagencral-purposeeventthatmay electronically punc^ each time the customer makes a 

be generated for any event th^X is of Stoest to the operated ^5 qualifying purdiase^ When a required numbex of punches 

offeecommercesystem.TheUser_J>efinedeventindudes have been made, the cu^omer receives a discount, e.g., 

the following data: sessionjld; servicc_Jd; date_time; "Buy 10, Get 1 Free or $10 off. 

user_defined_type, which is a user-defined field that idcn- CONCLUSION 
tifies the type of user-defined event being observed; and 

data__string, a string of data formatted according to the 20 In summary, the electronic mall is an example of a system 

needs of the developer. ardiitecture in which interface-compliant implementations 

VH Additional Features of these basic functional subsystems may be interconnected 

Variations on Above Disclosed Embodiment in a manner to suit the needs of a particular electronic 

a. Long-lived Sales Rq)resentative commerce participant ITie invention provides some sub- 
In the previously described embodiment of the invention, 25 systems tlirecUy (in the form of complete Internal Com- 

the Customer Monitoring Object/Sales Representative Pro- merce Subsystems), and other subsystems indirectly (in the 

gram Object 114 was created and terminated after each formofint^aces to External Commerce Subsystems), with 

shopping trip. In another embodiment of the invention, a eadi store being able to select the particular combination 

Sales Representative Program Object 114 may be longer- that best suits its specific needs. However, all subsystems, 

lived. Typically, Sales Representative Program Object ter- 30 whether External or Internal, are compatible with a set of 

mination is associated with customer billing. For exan^e, if standardized subsystem interfaces. At die front end, a cus- 

the Electronic Storefront uses monthly rather than session tomer shops in the electronic store through an Electronic 

billing, the Sales Representative Program Object 114 would Storefront, and at the back end, die store management 

be terminated at the end of die monthly shopping cycle interfaces with and controls the various subsystems through 

rather than at the end of each shopping trip. 35 a Store Management Dashboard. 

In cases where a customer's Sales Rqjresentative Fro- xhe operation of the system described above includes 

gram Object outlives the shopping trip during which die exemplary code for selected interfaces where it is illustrative 

Sales Rqjresentative Program Object was created, termina- of the operation of the subsystenL The soiree code is written 

tion of a shopping trip causes the Sales Representative using the Common Object Request Broker Architecture 

Program Object to become "dormant.*' typically, this is 40 (CORBA) Interface Definition Language (IDL). 

effected by causing information regarding that shopping trip ^ publications and existing subsystems mentioned in 

to be stored and, for example, flags/pointers to be set so diat specification are herein incorporated by reference to die 

die Sales Representative Program Object can be '"revived" ^^^^ as if each individual publication ca: existing 

or rccaUed at a later date. Subsequent shopping Rips can subsystems were specificaUy and individually indicated to 

tticn be initiated by recaUing the particular Sales Represen- 45 ^ incorporated by reference. 

tative ftogram Object assigned to tiiat aistom^. Thereafter, ^ ^ ^ skill in die art tiiat 

die transaction would proce^ as m the earker-d^bed changeslind modifications can be made tiiereto widi- 

^^.^^TT^^ out departing from tiie spirit or a scope of die appended 

Objcctwouldonly be terminated at die end of die shoppmg claims ^ *' 1- 

trip if customer billing was p^onned. 50 d^dxa: 

b. Sales Representative Program Object for Multiple Stores ^ ^ ^ facilitating commercial transactions. 
Similarly, die above descnption focuses on a Sales Rep- ^^^^^^ a phiraUty of customers and at least one suppUer of 

r^ntative Program Object assoaated widi a sm^e suK>lier ^^^^^ ^^^^ ^^^^^^ ^ ^ ^ 

ofitemssuchasastore.ftis,however,pos^leto^ oomiiunications between die suppUer and at least one 

Reprcsentaive Program Object can be created to attend to 55 ^^^t^^^ sjte associated witfi each customer and including 

a customer interacting widi a number of ^^PP^^-^ this ^ ^ comprising: 

embodiment, the Sales Representative Program Object can *^ . * / ^ 

maintainauWof aUitemsTelectedby dieLtomeraswell ^ for causing at least one supphex to be qp^e- 

as a reference to die supplier of each item. sented on die display for selection by die customer 

c. Frequent Buyex Incentives 60 usmg the i^ut means; 

L In-store Frequent Buyer Points b.meansforcfifectmgiwsentationof items on Redisplay 

Anodier type of in-store incentive is a frequent buyer customer observation; 

points program. Here, die in-store incentive takes die form c. an item database associated with a supplier and indud- 

of points issued to a customer's frequent buyer account Ing infoimation on presented items; 

rather than an instantaneous price discount The customer 65 d. pricing means for receiving infoimation from the item 

may redeem points at various levels to obtain actual price database to determine the cost associated with a pre- 

discounts. sented item; 
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e. a customer iiifon&ation database for stonng informa- 
tion relating to a customer; and 

f. means for creating a customer monitoring object for 
each customer by referencing information, relating to 
that customer, which had been stored in iht customer 
information database and upon the customer selecting 
at least one supplier such that the customer monitoring 
object is configured to q)erate by 

i. responding to customer enquiries, communicated 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infor- 
mation to the customer by means of the display, 

iL receiving a customer's selection of a presented item 
through the input means, 

iii. conmiunicating with the pridng means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of the 
display, 

V. receiving customer communications, through the 
input means, indicating a desire to receive the item, 
and 

vi. passing a delivery initiation conmrnmcation to ini- 
tiate the delivery of the item to the customer. 

2. The system of claim 1, further comprising a customer 
monitoring object configured to operate by: 

a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve information 
relating to said item and to present said information to 
the customer by means of the display, 

b. receiving a customer's selection of a presented item 
through the input means, 

c. communicating with the pricing means to have the cost 
of the item detomined, 

d. presenting the cost to die customer by means of the 
display, 

e. receiving customer communications, through the input 
means, indicating a desire to receive the item, 

f. passing a delivery initiation comnumicatioD to initiate 
the delivery of the item to the customer, and 

g. maintaining a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiadon commiinicatfon. 

3. The system of claim 2, wherein the custom^er monitor- 
ing object is configured to present the customer with an 
opportunity to deselect an item whereupon the customer 
monitoring object communicates with the pricing means to 
have the costs of the remaining selected items redetermined 
and presented anew to the customer. 

4. The system of claim 2, further comprising order ful- 
fillment initiation means, responsive to the delivery initia- 
tion communication firom the customer monitoring object, 
for initiating proceedings to cause the item desired by the 
customs delivered to die customer. 

5. The system of claim 4, wherein the order fulfillment 
means includes an interface wi^ a shipping facility fa: 
facilitating the shq>ping of the desired item to the customer. 

6. The system of claim 2, fixrther comprising a payment 
handler means for initiating customer paymient for the 
desired kern. 

7. The system of claim 6, wherein die payment handler 
means is responsive to comnumications firom the customer 
monitoring object and receives information from die cus- 
tomer identification database in order to initiate customer 
payment 
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8. The system of daim 7, wherein the aistomer monitor- 
ing object is configured to confirm to the customer that the 
order for the item has been successfully processed 

9. The system of daim 2, further comprising a payment 
s validation system induding 

means for causing the customer monitoring object to 
receive the information related to die forms of payment 
available to the customer and to present the customer 
with a sdection of the forms of payment; 

IQ means for recdving a first security code, rdated to a 
sdected form of payment, firom the customer; and 
means for validating the first security code by coinparison 
to a second securi^ code available to the customer 
monitoring object; 

j3 whereby payment for the item is initiated if the first 
security code is validated. 

10. The system of daim 2, further comprising a cost 
discount storage for maintaining cost reduction information 
associated with a supplier's it^is, 

^ wherdn the pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
assodated item. 

11. The system of daim 10, wherein the customer moni- 
toring object is configured to receive cost reduction inSos- 
mation communicate die reduction information to the pnc- 

25 ing means. 

12. The system of daim 11, wherein the customer moni- 
toring object is configured to confirm to the customer that 
the ordo- for die item has been successfully processed. 

13. The system of claim 12, wherein the supplier control 
30 means is configured to recdve input, from a supplier at a fiLrst 

time, to define changes to the cost reduction infarmation for 
a second time later dian the first time. 

14. The system of daim 11, further con^irising supplier 
control means for receiving input, from a supplier, for 

35 changing the cost reduction information. 

15. The system of daim 2, further comprising means, 
responsive to an input from the customer, to terminate the 
customer's interaction with die supplier whereupon which 
termination the customer monitoring object ceases to oper- 

40 ate. 

16. The system of daim 2, further conqnising means, 
responsive to an input from die customer, to terminate the 
customer's interaction with the suppHer whereupon the 
customer monitoring object ceases to operate and informa- 

45 tion regarding at least the interaction is stored for retrieval 
at a subsequent time at which the customs interacts with the 
suppHer whereby the customer monitoring object recom- 
mences operation utilizing the stored infonnation. 

17. The system of daim 16, wherein the partidpant 
50 program object indudes information related to forms of 

payment available to the customer. 

18. The system of claim 2, further con^xrising means for 
accessing the customer information database and fc^ creat- 
ing a partidpant program object induding information spe- 

SS dfic to the customer retrieved from the inf (Hmation database 
and in communication with and for passing customer spe- 
cific information the customer monitoring object. 

19. Hie system of daim 18, wherein the partidpant 
program otrject is created at the time an interaction between 

60 the customer and the system commences. 

20. The system of claim 2, further comprising an obser- 
vation subsystem for receiving and maintaining customer 
interaction information relating to at least one customer's 
communications over the computer driven network. 

65 21. The system of daim 20, further comprising sujiplier 
control means for recdving input, from a supplier, for 
changing the cost reduction information. 
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22. The system of claim 21, wherem the supplier control 
means is configured to receive input, from a supplier at a first 
time, to de&ne changes to the cost reduction infonnation for 
a second time later than the first tune. 

23. The system of claim 22 wherein the supplier control 
means is in communication with the observation subsystem 
to receive customer interaction information for display to the 
supplier. 

24. The system of daim 23, wherein the supplier control 
indudes: 

a. an information processor for processing received cus- 
tomer interaction information; and 

b. means for selectivdy displaying at least a part of the 
processed customer interaction information to the sup- 
plier. 

25. The system of claim 2 wherein the means for causing 
at least one suH)lier to be represented can cause a plurality 
of suppliers to be represented, the system further comprising 
means to enable a customer to select at least one of the 
represented suppliers. 

26. A system for facilitating commercial transactions, 
between a plurality of customers and at least one supplier of 
items, over a computer driven network capable of providing 
communications between the supplier and at least one 
customer site associated with each customer and induding 
an input means and a display, the system comprising: 

a. means for causing at least one supplier to be repre- 
sented on the display for sdection by the customer 
using the input means; 

b. means for effecting presentation of items on the display 
for customer observation; 

c. an item database associated with a supplier and indud- 
ing information on presented items; 

d. pricing means for receiving information from the item 
database to determine the cost assodated with a pre- 
sented item; 

e. a customer information database for storing informa- 
tion rdating to a customer; and 

f. means for creating a customer monitoring object for 
each customer by referencing infonnation, relating to 
that customer, which had been stcred in the customer 
information database and upon the customer selecting 
at least one supplier such that the customer monitoring 
object is configured to operate by 

i. responding to customer enquiries, communicated 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infor- 
mation to the customer by means of the display, 

iL recdving a customer's selection of a presented item 
dirough the input means, 

iii. communicating with the pricing means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of the 
display, 

V. recdving customer communications, through the 
input means, indicating a desire to receive the item, 

vi. passing a delivery initiation comnuinication to ini- 
tiate the delivery of the item to the customer; and 

g. a means for accessing the customer information data- 
base and for creating a partidpant program object 
induding information specific to the customer retrieved 
from the information database and in communication 
with and for passing customer specific information to 
the custonier monitoring object 

27. The system of claim 26, further comprising a customer 
monitoring object configured to operate by: 



a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve information 
relating to said item and to present said information to 

5 the customer by means of the display, 

b. recdving a customer's selection of a presented item 
through the input means, 

c. communicating with the pricing means to have the cost 
of the item determined, 

10 d. presenting the cost to the customer by means of the 
display, 

e. receiving customer communications, through the input 
means, indicating a desire to recdve the item, 

f. passing a delivoy initiation communication to initiate 
15 the delivery of the item to die customer, and 

g. maintaining a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiation communication. 

2Q 28. The system of claim 27, wherein the customer moni- 
toring object is configured to present the customer with an 
opportunity to deselect an item whereupon the customer 
monitoring object communicates with the pricing means to 
have the costs of the renaming sdected items redetermined 
and presented anew to the customer. 
^ %9. The system of daim 27, further comprising order 
fulfillment initiation means, responsive to the delivery ini- 
tiation communication from the customer monitoring object, 
for initiating proceedings to cause die item desired by the 
customer delivered to the customer. 

30. The system of claim 27, wherdn the order fulfillment 
means indudes an interface witii a shipping facility for 
facilitating the shipping of the desired item to the customer. 

31. The system of daim 27, further comprising a payment 
handler means for initiating customer payment for the 
desired item. 

32. The system of daim 31, wherein the payment handler 
means is responsive to communications from the customer 
monitoring object and recdves information from the cus- 
tomer identification database in order to initiate customer 

^ payment 

33. The system of daim 27, further comprising a payment 
validation system induding 

means for causing the customer monitoring object to 
receive the information related to the forms of payment 
available to the customs and to present the customer 
with a sdection of the forms of payment; 
means for recdving a first security code, rdated to a 
sdected form of payment, firom the customer; and 
50 means for validating the first security code by comparison 
to a second security code available to the customer 
monitoring object; 
whereby payment for the item is initiated if the first 
security code is validated. 
55 34. The system of daim 27, further comprising a cost 
discount storage for maintaining cost reduction infonmtion 
associated with a supplier's items, 
wherein die pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
60 assodated item. 

35. The system of daim 34, wherein the customer moni- 
toring object is configured to receive cost reduction infor- 
mation communicate the reduction information to the pric- 
ing means. 

6S 36. The system of daim 35, further comprising means for 
receiving input, from a supplier, for changing the cost 
reduction information. 
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37. The system of claim 36, wherein the supplier control 
means is configured to receive input, from a supplier at a first 
time, to define changes to the cost reduction infonnation for 
a second time later than the first time. 

38. The system of claim 27, further comprising means, 
responsive to an input from the customer, to terminate the 
customer's interaction with the supplier upon which tcrmi- 
nation the customer monitoring object ceases to operate. 

39. The system of claim 27, further comprismg means, 
responsive to an input from the customer, to terminate the 
customer's interaction with the supplier whereupon the 
customer monitoring object ceases to operate and informa- 
tion regarding at least the interaction is stored for retrieval 
at a subsequent time at which the customer interacts with the 
supplier whereby the customer monitoring object recom- 
mences operation utilizing the stored information. 

40. The system of daim 27, wherein the participant 
program object is created at the time an interaction between 
the customer and the system commences. 

41. The system of daim 40, wherein the partidpanl 
program object indudes information related to forms of 
payment available to the customer. 

42. The system of daim 27, further comprising means for 
causing at least one suppli^ to be represented on the display 
and means for receiving an input from die customer indi- 
cating a sdection of a represented supplier. 

43. Hie system of daim 42, whereby said means for 
creating a customer monitoring 6bject creates the customer 
monitoring object for the customer when the customer 
selects the supplier. 
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44, The system of daim 27, further comprising an obser- 
vation subsystem for receiving and maintaining customer 
interaction information relating to at least one customer's 
communications over the counter driven network. 
3 45. Tlie system of claim 44, further comprising supplier 
control means for recdving input, from a supplier, for 
changing the cost reduction information. 

46. The system of claim 45, wherein the supplier confrol 
means is confi.gured to recdve input, from a supplier at a first 
time, to define changes to the cost reduction information for 
a second time later than the first time. 

47. The system of daim 46, wherein the supplier control 
means is in conomunication with the observation subsystem 

J J to recdve customer interaction information for display to the 
supplier. 

48. The system of claim 47, wherein the supplier control 
means indudes: 

a. an information processor for processing recdved cus- 
20 tomer interaction information; and 

b. means for sdectivdy displaying at least a part of the 
processed customer interaction information to the sup- 
plier. 

49. The system of daim 26 wherein Hxc means for causing 
25 at least one supplier to be represented can cause a plurality 

of suppliers to be rq>resented, the system further comprising 
means to enable a customer to select at least one of the 
represented suppliers. 

nt m * * * 
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